這是好幾年前的故事，主角是我一個好朋友 Anthony，當時他在一間新創軟體公司當技術主管。
有一天老闆把 Anthony 叫到辦公室裡面去問了某專案的進度，Anthony 當下沒有馬上回答，而是回去把他的電腦拿來，在老闆面前打開了工作待辦清單，稍微看了一下，指著螢幕，就給出了一個「大約一個半月以後會開工，兩個月之內就可以上線」的估算。
「在那之後老闆也沒有再繼續跟我追蹤了」，Anthony 這麼跟我說。兩個月之後有一天，老闆又出現在他面前，問他說上次那個專案的情況如何。Anthony 還是一樣打開同一份待辦清單，指出同一個專案，並說：「這個現在已經完成了，等到本週五上線日，就會跟著一起上線，用戶就可以使用這個功能了。」
「那時是我跟這位老闆第一次的合作，所以對方有點驚訝。」Anthony 表示，離開前老闆最後一句講的話是：「怎麼會這麼準。」
Anthony 的故事，最後一小段是在那之後有一次，他與老闆一起去跟股東開會，開完會大家在聊天，這時股東對上面的那個故事非常的有興趣，劈頭就問 Anthony 說：「你到底是怎麼估算得這麼準的？我們的 PM 每次估的上線日都會 Delay，不然就是會出一大堆 Bug，你可不可以教我們的人也估算一下？」
其實，各位讀者追本系列文章至此也都知道了，哪有估算得準這種事？這些東西都不是估算出來的，這些東西都是看出來的。
各位有聽過 PDCA Cycle 嗎？這是指我們要完成一件事的四個流程：
說穿了，敏捷開發從頭到尾其實是一個快速而持續的 PDCA 的過程。我們把一個很大的長期產品切割成一塊一塊的小部分，每個小部分做完的時候都回頭去看產品新的樣貌，並且決定下一個小部分要做什麼，什麼東西要加進來、什麼東西要丟掉，什麼事是我們這次沒做好，下次可以改善的。
坊間流行的敏捷開發的一些框架，你如果仔細看的話，會發現它們對於開發者的軟體硬實力是沒有太多著墨的，取而代之的是開發者的軟實力，譬如說溝通能力，譬如說紀律。
Kent Beck 曾經說：「我不是一個很優秀的開發者，而我是一個還不錯的開發者，但有非常好的紀律。」
這些敏捷開發的框架，例如含 Scrum、看板、Extreme Programming 等等，他們強調的都是個人的紀律、團隊成員間的紀律、團隊對外的紀律，都沒有在強調硬實力。你從來不會在任何一個敏捷開發的書或文章裡面看到資料結構、演算法、計算機系統，或網路底層原理。為什麼？因為要完成你的工作，你本來就需要這些東西。就算別人不講，你不會的話本來就做不到。
敏捷開發想要做的事情其實是：在你開發時，把其它一些能夠阻礙你的外部因素全部排除掉，讓你能夠專心的發揮你原本就擁有的硬實力，進而助你取得持續而穩定的步調。
有了持續而穩定的步調、公開透明的流程，當任何 Stakehoker 問起進度或預期上線時間的時候，你給出的預估就算有誤差也不會太多吧？這就是 Uncle Bob 在 Clean Agile 裡說的：
「Sprint 不會失敗，它要嘛給我們功能，要嘛給我們 Data。」
至於要怎麼提供持續穩定的步調呢？
Uncle Bob 在 Clean Craftsmanship 一書裡面有提到一個很重要的概念：「我們不交付大便」。
「開玩笑吧！誰會沒事交付大便啦？」
其實呢，Uncle Bob 的意思是：
簡單來說，每當你違反開發人員的軟體紀律的時候，你交付出來的東西都是大便。
這意味著我們就要以遵守規定為目的而來開發嗎？不對的，這意味著當我們的東西從我們的手中交出去的時候，我們必須要有信心，我們已經把該做的事情好好地做完了。這裡指的不是功能，而更包含輸入程式碼以外的工作。舉例來說，當我們把手上開發好的功能交給 QA 測試的時候，我們應該要有信心，所有功能性的測試在我們能做的範圍內，我們都測完了，否則我們就不能聲稱我們已經做完。這樣子的嚴守紀律的工作方式，可以讓我們面對任何外在情況改變時，調整的成本都要不會太高，因為我們每次的改動範圍都不會太大。
何謂軟體？軟體指的是相對於硬體，比較容易改動的東西吧？那既然身為軟體工程師，當我們想要對 Stakeholder 提出一個反駁叫做「這個改動很大，我們很難做」的時候，我們其實應該要檢討自己，是否我已經把軟體給做硬了。
敏捷開發、軟體重構、單元測試、整合測試等，這些方法都不會幫助你提升硬實力，你寫程式的速度也不會變快，但是這些事情如果做得好，你的軟體每次的改動範圍都會跟你的需求的大小成正比。什麼意思？你有沒有遇過一個情況：當客戶請你改一點點小東西，但是你實際上程式內部的改動卻會很大？如果有，這很有可能代表你前面的這些軟體紀律的事情沒有做的很好，你才會因為一個改動需求而不得不修改很大的範圍。
這就是你軟體流程跟機率的壞味道了。當然，Uncle Bob 拿大便出來比喻是一個比較激烈的用詞，事實上他代表的就是一個缺乏紀律、會降低生產力的工作方式。
那麼？紀律是怎麼影響生產力的？
身為一個負責任的軟體工程師，你應該要時時刻刻都為自己準備好。準備好什麼。準備好交付。
什麼意思？
這個牽扯到我們經常講的 DoD：Definition of Done（完成的定義）。 也許你有聽過一句開玩笑話，叫做「在我電腦上是好的」，但事實上很多人真的在職場上遇過或是很想講這句話。當你想講這句話的時候就代表你的 DoD 太初階了，你的 DoD 離交付太遠了，因為當你每個工作號稱做完的時候，離交付都還有一大段距離，這同時也代表你離這一個產品功能要真正產生商業價值，還要再多付出一些成本。如果這個成本能夠時時刻刻保持在一個接近於 0的狀態（不一定要完全是 0），這時你就很接近 Uncle Bob 所說的，時時刻刻為交付準備好。
當你時時刻刻都為交付做好準備，你的生產力就會穩定，所謂的生產力穩定就是當今天你的實力是一個月做五個大小中等的功能，那麼你就應該每個月都大約做五個這麼大的功能，而不會因為你的系統越長越大而越做越少，而且全世界都知道這件事，包括你的老闆。
當你有辦法表現出這樣子的穩定生產力的時候，你的估算就可以在別人眼中看起來準一點。準一點有什麼好處？我們今天是軟體開發者，我們的開發是為了實現 Stakeholders 的商業利益，如果你的生產力是穩定的，那麼 Stakeholders 對於什麼時候要做什麼決策就會比較有信心。想反的，如果你的生產力不穩定，他根本就沒有辦法預估你說好的交付日是否會跳票。當他沒有辦法預估你什麼時候能交付的，他會做什麼？他別無選擇，只好為自己加 Buffer。當 Stakeholders 想要為自己加 Buffer 的時候，你就只好加班了。
說到加班，當你今天遇到生產力下降導致的時間壓力，而不得不加班時，若想解決這個問題，你有哪些選擇？
管理人員經常會試圖通過「增加人力」來對付生產力下降的情況，但我們都讀過人月神話，我們都知道這種策略很少成功的，因為新加入團隊的開發者對於戰力的補強是非常有限的。在進度壓力下，新人會做什麼事？我相信 10 個有 10 個都會為了盡快趕上進度而而模仿舊有成員的工作方式。然而，這個專案不就是因為舊有成員的工作方式缺乏紀律而越做越慢嗎？於是你不管加多少人，根本的原因都不會被解決，只是讓擁有不好開發習慣的人越來越多而已。
「一人公司」這本書，強調的並不是每間公司都只能有一個人，它闡述了一個很重要的思考邏輯，叫做「質疑成長」。這不是說人多一定不好，而是任何時候你想要靠擴大團隊來解決速度的問題的時候，你應該要優先考慮原本內部的問題都解決完了嗎？如果這些問題都沒有解決，你只是把同樣效率低下的工作模式再擴大範圍而已，而更有甚者，經驗告訴我們，當你團隊成長的時候，效率不會保持原樣，絕大多數都是更低而已。軟體管理大師老早就告訴我們了，軟體開發的問題都是人的問題，而越多人就越容易出現複雜的問題。
「那我們就不該擴大了嗎？」
也不是的，我們還是可以擴大，但是我們必須得先思考：「現在眼前的問題是擴大能解決的嗎？」、「現在擴大了以後所產生的新問題，我們現在團隊的狀況承受得了嗎？」
筆者自己的經驗是這樣的，當我們今天團隊想要擴大，必須建立在一個我們的交付速度跟開發品質都已經在一個穩定的階段了。這時我們再來招募新同事時，剛進來的新同事他可不可以學習舊有同事的開發習慣？可以，因為這個開發習慣是我們覺得效率不錯的。同時，新同事可不可以帶來新的思想？當然很好，因為這時候舊同事本來就已經在一個穩定而有效率的開發模式底下工作了，他自然有餘裕去學習新同事帶來的新工作方式。
在穩定而持續的開發步調下逐漸的擴大團隊，在筆者的經驗裡面是最有效率，而且風險可控的擴大團隊工作方式。
謎之聲：「嚴守紀律，維持品質，穩定擴大，可預估時程。」
iThome鐵人賽
看影片追技術